The Border Gateway Protocol (BGP) was originally developed in the late 1980s and at the beginning of the 1990s and has evolved into a widely used, mature protocol for interconnecting network domains, i.e. interconnecting autonomous systems (AS). As of November 2012, the current version of BGP is defined in Y. Rekhter et al, “RFC 4271: A Border Gateway Protocol 4 (BGP-4)”, The Internet Society, Network Working Group, January 2006. BGP may for example be used to interconnect network domains operated by different service providers, such as different Internet service providers (ISPs). BGP is a protocol designed to exchange reachability information, i.e. information between routers as to which destination networks are reachable through which routers. BGP is designed to carry information about the path to be traversed by reachability information. The information is carried in a manner suppressing information looping and allowing incremental updates, i.e. sending only the changes in the reachability information, rather than periodically sending all the reachability information to all routers.
BGP is a path vector protocol. Each entry in a BGP routing table comprises the destination network, the next router, i.e. the next hop, and the path to reach the destination network.
BGP-capable routers are called BGP speakers. Neighbour BGP speakers are called BGP peers. Two BGP peers communicate with each other through a BGP session. A BGP speaker maintains, for each BGP session, a state variable in accordance with a finite state machine.
In a so-called full interior BGP mesh, all the reachability information is distributed to all BGP speakers within an AS as well as across autonomous system borders. To do so, within an AS, BGP sessions need to be established between each pair of BGP speakers. In practice, therefore, BGP sessions are established between each pair of border routers of an AS. Such a full-mesh solution is simple in terms of implementation. However, with the growth of the Internet, the size of most AS has significantly increased and, consequently, the size of the full meshes within these AS has significantly increased as well.
A solution to cope with this problem is route reflection, which involves the distribution of reachability information in accordance with the hub-and-spoke principle. Namely, a router in the AS acts as a hub for the distribution of the reachability information. Such a router is called a router reflector (RR). Route reflection significantly reduces the number of BGP sessions to be established within an AS and therefore leads to more efficient intra-domain connectivity. Furthermore, there may be more than one RR in an AS. Regarding route reflection, see also for example T. Bates et al, “RFC 2796: BGP Route Reflection-An Alternative to Full Mesh IBGP”, The Internet Society, Network Working Group, April 2000.
In order to provide efficient inter-domain connectivity, constraining the distribution of reachability information through route filters may be used. Reachability information is marked and then distributed across the domains, or not, depending on how the reachability information is marked. In other words, reachability information is filtered out based on markers. For example, the use of Route Target (RT) communities enables to specify that, within a particular router, all the reachability information marked as belonging to a particular RT Community should, or should not, be filtered out. A Route Target community is a BGP extended community that conditions network layer reachability information based on virtual private network (VPN) membership, in applications that will now be explained.
Nowadays, BGP is also used to support other applications than traditional Internet applications, for example to carry reachability information for virtual private networks (VPNs). These developments have been made possible notably because the reachability information carried by BGP is not limited to IPv4 and IPv6 prefixes. In particular, the so-called BGP/MPLS VPNs (also known as 2547 VPNs) and BGP for VPN auto-discovery applications have been developed.
In the above-mentioned BGP/MPLS VPNs application, BGP is used to distribute VPN reachability information across a provider backbone and Multiprotocol Label Switching (MPLS) is used to transport VPN traffic from one VPN site to another over the provider backbone. The provider backbone may be made of several interconnected domains, each operated by a service provider. For example, E. Rosen et al, “RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)”, The Internet Society, Network Working Group, February 2006, describes a method by which a service provider may use an Internet Protocol (IP) backbone to provide IP VPNs for its customers. The purpose of a VPN is to maintain privacy of communication and address space. This method will be briefly explained with reference to FIGS. 1 to 4.
FIG. 1 schematically illustrates a set of four “sites” (the customer sites) attached to a common network (the IP backbone). The IP backbone, which is owned and/or operated by a service provider, provides an IP service to the customer. For example, a first VPN (VPN1) may involve customer sites 1 and 3 whereas a second VPN (VPN2) may involve customer sites 2 and 4.
The customer may attach to the backbone via a layer 2 service, but the layer 2 service is terminated at the “edge” of the backbone, where the customer's IP datagrams are removed from any layer 2 encapsulation, as schematically illustrated by FIG. 2.
As explained in RFC 4364, section 1.2, first paragraph, at the edge of a backbone, routers “can be attached to each other, or to end systems, in a variety of different ways: PPP connections, ATM Virtual Circuits (VCs), Frame Relay VCs, ethernet interfaces, Virtual Local Area Networks (VLANs) on ethernet interfaces, GRE tunnels, Layer 2 Tunneling Protocol (L2TP) tunnels, IPsec tunnels, etc.” The term “attachment circuit” refers to the means of attaching to a router, as schematically illustrated in FIG. 3, so that two devices can be network layer peers over the attachment circuit.
In that context, and still referring to FIG. 3, each VPN site, i.e. customer sites 1 to 4, comprises at least one customer edge (CE) devices (although a customer site may be involved in more than one VPN). For example, CE device CE1 belongs to customer site 1, CE device CE2 belongs to customer site 2, etc. Each CE device is attached, through an attachment circuit, to one or more provider edge (PE) routers. For example, CE device CE1 is attached to PE router PE1, CE device CE2 is attached to PE router PE2, etc. Routers in the service provider's network (i.e., in the backbone) that do not attach to CE devices are known as P routers.
BGP is used by the service provider to exchange the reachability information, also called simply routes, of a particular VPN among the PE routers that are attached to that VPN. In BGP, a route is a unit of information that pairs a set of destinations with the attributes of a path to those destinations. The set of destinations are systems whose IP addresses are contained in one IP address prefix carried in the network layer reachability information (NLRI) field of a BGP update message. The path is the information reported in the path attributes field of the same BGP update message (RFC 4271, section 1.1). Routes are advertised between BGP speakers in update messages.
As explained in RFC 4364, BGP is used by the service provider to exchange the routes of a particular VPN among the PE routers that are attached to that VPN in a manner that ensures that routes from different VPNs remain distinct and separate, even though two VPNs may have an overlapping address space. Each route within a VPN is assigned a MPLS label. When BGP distributes a VPN route, it also distributes an MPLS label for that route. The PE routers distribute, to the CE routers in a particular VPN, the routes from other CE routers in that VPN. In such a manner, user data packets can be tunnelled through the service provider backbone, after having been encapsulated with the MPLS label corresponding to the customer's VPN and further encapsulated so that the packets is tunnelled across the service provider backbone to the proper PE router.
RFC 4364, section 4.3.2, explains how routes may be distributed among PE routers. Namely, if two sites of a VPN attached to PE routers that are in the same AS, the PE routers can distribute VPN-IPv4 routes to each other by means of a BGP connection between them. Alternatively, each can have an IBGP connection to a route reflector (RR), as explained above.
The same principles apply to the case of a multi-provider backbone, as schematically illustrated by FIG. 4. An autonomous system border router (ASBR) is a router located at the border between two AS operated by different service providers.
Furthermore, in the above-mentioned BGP for VPN auto-discovery application, BGP can be used so that a VPN can auto-discover its members in the sense that the set of PE routers having a VPN in common is identified. In other words, BGP is used to auto-discover the end points of a VPN. Instead of configuring a PE router with information about all the other PE routers of a given VPN, the PE router uses BGP to discover the other PE routers. Using Route Targets, the PE router announces to its BGP neighbours that it belongs to a particular VPN.
Regarding VPN auto-discovery using BGP, see for example K. Kompella et al, “RFC 4761: Virtual Private LAN Service (VPLS), Using BGP for Auto-Discovery and Signaling”, The IETF Trust, Network Working Group, January 2007 (notably section 3.1), and K. Kompella et al, “RFC 6624: Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling”, Internet Engineering Task Force (IETF), May 2012.
It is desirable to improve the methods for setting up connectivity between PE routers of VPN(s) provided over a backbone, with in mind the need to reduce the provisioning burden on the service provider(s). This aim should be met without increasing, or at least without excessively increasing, the implementation and architecture complexity and the associated equipment costs.